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Abstract 
This document describes the procedures used by the IESG for handling 
documents submitted for RFC publication from the Independent 
Submission and IRTF streams. 
This document updates procedures described in RFC 2026 and RFC 3710. 
Status of This Memo 


This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at http://www.rfc- 
editor.org/info/rfc5742. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the BSD License. 
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1. Introduction and History 


RFC 4844 [N1] defines four RFC streams. When a document is submitted 
for publication, the review that it receives depends on the stream in 
which it will be published. The four streams defined in RFC 4844 
are: 


- The IETF stream 

- The IAB stream 

- The IRTF stream 

—- The Independent Submission stream 


The IETF is responsible for maintaining the Internet Standards 
Process, which includes the requirements for developing, reviewing 
and approving Standards Track and BCP RFCs. These RFCs, and any 
other IETF-generated Informational or Experimental documents, are 
reviewed by appropriate IETF bodies [N2] and published as part of the 
IETF stream. 


Documents published in streams other than the IETF stream might not 
receive any review by the IETF for such things as security, 
congestion control, or inappropriate interaction with deployed 


protocols. Generally, there is no attempt for IETF consensus or IESG 
approval. Therefore, the IETF disclaims, for any of the non-IETF 
stream documents, any knowledge of the fitness of those RFCs for any 
purpose. 


IESG processing described in this document is concerned only with the 
last two categories, which comprise the Independent Submission stream 
and the IRTF stream, respectively [N1]. 


Following the approval of RFC 2026 [N2] and prior to the publication 
of RFC 3932 [I1], the IESG reviewed all Independent Submission stream 
documents before publication. This review was often a full-scale 
review of technical content, with the Area Directors (ADs) attempting 
to clear points with the authors, stimulate revisions of the 
documents, encourage the authors to contact appropriate working 
groups (WGs), and so on. This was a considerable drain on the 
resources of the IESG, and because this was not the highest priority 
task of the IESG members, it often resulted in significant delays. 


In March 2004, the IESG decided to make a major change in this review 
model, with the IESG taking responsibility only for checking for 
conflicts between the work of the IETF and the documents submitted. 
Soliciting technical review is deemed to be the responsibility of the 
RFC Editor. If an individual AD chooses to review the technical 
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content of the document and finds issues, that AD will communicate 
these issues to the RFC Editor, and they will be treated the same way 
as comments on the documents from other sources. 


Prior to 2006, documents from the IRTF were treated as either IAB 
submissions or Independent Submissions via the RFC Editor. However, 
the Internet Research Steering Group (IRSG) has established a review 
process for the publication of RFCs from the IRTF stream [I2]. Once 
these procedures are fully adopted, the IESG will be responsible only 
for checking for conflicts between the work of the IETF and the 
documents submitted, but results of the check will be reported to the 
IRTF. These results may be copied to the RFC Editor as a courtesy. 


This document describes only the review process done by the IESG when 
the RFC Editor or the IRTF requests that review. The RFC Editor will 
request the review of Independent Submission stream documents, and 
the IRTF will request review of IRTF stream documents. There are 
many other interactions between document editors and the IESG, for 
instance, an AD may suggest that an author submit a document as input 
for work within the IETF rather than to the RFC Editor as part of the 
Independent Submission stream, or the IESG may suggest that a 
document submitted to the IETF is better suited for submission to the 
RFC Editor as part of Independent Submission stream, but these 
interactions are not described in this memo. 


For the convenience of the reader, this document includes description 
of some actions taken by the RFC Editor, the IAB, and the IRSG. The 
inclusion of these actions is not normative. Rather, these actions 
are included to describe the overall process surrounding the 
normative IESG procedures described in this document. No RFC Editor, 
IAB, or IRSG procedures are set by this document. 


1.1. Changes since RFC 3932 
RFC 3932 provided procedures for the review of Independent Submission 
stream submissions. With the definition of procedures by the IRSG 
for the IRTF stream, it has become clear that similar procedures 


apply to the review by the IESG of IRTF stream documents. 


The IAB and the RFC Editor have made updates to the formatting of the 


title page for all RFCs [N3]. With these changes, the upper left 
hand corner of the title page indicates the stream that produced the 
RFC. This label replaces some of the information that was previously 


provided in mandatory IESG notes on non-IETF-stream documents. 
The IESG may request the inclusion of an IESG note in an Independent 


Submission or IRTF stream document to explain the specific 
relationship, if any, to IETF work. In case there is a dispute about 
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the content of the IESG note, this document provides a dispute 
resolution process. 

2. Background Material 
The review of Independent Submissions by the IESG was prescribed by 
RFC 2026 [N2], Section 4.2.3. The procedure described in this 


document is compatible with that description. 


The procedures developed by the IRTF for documents created by the 
Research Groups also include review by the IESG [I2]. 


The IESG Charter (RFC 3710 [I5], Section 5.2.2) describes the review 
process that was employed in Spring 2003 (even though the RFC was not 
published until 2004); with the publication of RFC 3932 [I1], the 
procedure described in RFC 3710 was no longer relevant to documents 
submitted via the RFC Editor. The publication of this document 
further updates Section 5.2.2 of RFC 3710, now covering both the IRTF 
and the Independent Submission streams. 


3. Detailed Description of IESG Review 


The RFC Editor reviews Independent Submission stream submissions for 
suitability for publication as RFCs. As described in RFC 4846 [I3], 
the RFC Editor asks the IESG to review the documents for conflicts 
with the IETF standards process or work done in the IETF community. 


Similarly, documents intended for publication as part of the IRTF 
stream are sent to the IESG for review for conflicts with the IETF 
standards process or work done in the IETF community [I2]. 


The IESG review of these Independent Submission and IRTF stream 
documents results in one of the following five types of conclusion, 
any of which may be accompanied by a request to include an IESG note 
if the document is published. 


1. The IESG has concluded that there is no conflict between this 
document and IETF work. 


2. The IESG has concluded that this work is related to IETF work done 
in WG <X>, but this relationship does not prevent publishing. 


3. The IESG has concluded that publication could potentially disrupt 


the IETF work done in WG <X> and recommends not publishing the 
document at this time. 
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4. The IESG has concluded that this document violates IETF procedures 
for <Y> and should therefore not be published without IETF review 
and IESG approval. 


5. The IESG has concluded that this document extends an IETF protocol 
in a way that requires IETF review and should therefore not be 
published without IETF review and IESG approval. 


The RFC headers and boilerplate [N3] is intended to describe the 
relationship of the document to the IETF standards process. In 
exceptional cases, when the relationship of the document to the IETF 
standards process might be unclear, the IESG may request the 
inclusion of an IESG note to clarify the relationship of the document 
to the IETF standards process. Such a note is likely to include 
pointers to related IETF RFCs. The dispute resolution process in 
Section 4 is provided to handle situations in which the IRSG or RFC 
Editor is concerned with the content of the requested IESG note. 


The last two responses are included respectively, for the case where 
a document attempts to take actions (such as registering a new URI 
scheme) that require IETF Review, Standards Action, or IESG Approval 
(as these terms are defined in RFC 5226 [16]), and for the case where 
there is a proposed change or extension to an IETF protocol that was 
not anticipated by the original authors and that may be detrimental 
to the normal usage of the protocol, but where the protocol documents 
do not explicitly say that this type of extension requires IETF 
review. 


If a document requires IETF review, the IESG will offer the author 
the opportunity to ask for publication as an AD-sponsored individual 
document, which is subject to full IETF review, including possible 
assignment to a WG or rejection. Redirection to the full IESG review 
path is not a guarantee that the IESG will accept the work item, or 
even that the IESG will give it any particular priority; it is a 
guarantee that the IESG will consider the document. 


The IESG will normally complete review within four weeks of 
notification by the RFC Editor or IRTF. In the case of a possible 
conflict, the IESG may contact a WG or a WG Chair for an outside 
opinion of whether publishing the document is harmful to the work of 
that WG and, in the case of a possible conflict with an IANA 
registration procedure, the IANA expert for that registry. 


If the IESG does not find any conflict between an Independent 
Submission and IETF work, then the RFC Editor is responsible for 
judging the technical merits for that submission, including 
considerations of possible harm to the Internet. If the IESG does 
not find any conflict between an IRTF submission and IETF work, then 
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the IRSG is responsible for judging the technical merits for that 
submission, including considerations of possible harm to the 
Internet. 


The RFC Editor, in agreement with the IAB, shall manage mechanisms 
for appropriate technical review of Independent Submissions. 
Likewise, the IRSG, in agreement with the IAB, shall manage 
mechanisms for appropriate technical review of IRTF submissions. 


4. Dispute Resolution 


Experience has shown that the IESG and the RFC Editor have worked 
well together regarding publication recommendations and IESG notes. 
Where questions have arisen, they have been quickly resolved when all 
parties become aware of the concerns. However, should a dispute ever 
arise, a third party can assist with resolution. Therefore, this 
dispute procedure has an informal dialogue phase followed by an 
arbitration phase if the matter remains unresolved. 


If the IESG requests the inclusion of an IESG note and the IRSG or 
the RFC Editor intends to publish the document without the requested 
IESG note, then they must provide a clear and concise description of 
the concerns to the IESG before proceeding. A proposal for alternate 
IESG note text from the IRSG or the RFC Editor is highly encouraged. 


If the IESG does not want the document to be published without the 
requested IESG note, then the IESG must initiate an informal 
dialogue. The dialogue should not take more than six weeks. This 
period of time allows the IESG to conduct an IETF Last Call 
concerning the content of the requested IESG note (and not on the 
document as a whole) to determine community consensus if desired. At 
the end of the dialogue, the IESG can reaffirm the original IESG 
note, provide an alternate IESG note, or withdraw the note 
altogether. If an IESG note is requested, the IRSG or the RFC Editor 
must state whether they intend to include it. 


If dialogue fails to resolve IRSG or RFC Editor concerns with the 
content of a requested IESG note and they intend to publish the 
document as an RFC without the requested IESG note, then the IESG can 
formally ask the IAB to provide arbitration. The IAB is not 


obligated to perform arbitration and may decline the request. If the 
IAB declines, the RFC Editor decides whether the IESG note is 
included. If the IAB accepts, the IAB review will occur according to 


procedures of the IAB’s own choosing. The IAB can direct the 
inclusion of the IESG note, direct the withdrawal of the IESG note, 
or leave the final decision to the RFC Editor. Unlike the IAB 
reviews specified in RFC 4846 [13], if the IAB directs the inclusion 
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or withdrawal the IESG note, the IAB decision is binding, not 
advisory. 


5. Examples of Cases Where Publication Is Harmful 


This section gives a couple of examples where delaying or preventing 
publication of a document might be appropriate due to conflict with 
IETF work. It forms part of the background material, not a part of 
the procedure. 


Rejected Alternative Bypass: 


As a WG is working on a solution to a problem, a participant 
decides to ask for Independent Submission stream publication of a 
solution that the WG has rejected. Publication of the document 
will give the publishing party an RFC number before the WG is 
finished. It seems better to have the WG product published first, 
and have the non-adopted document published later, with a clear 
disclaimer note saying that "the IETF technology for this function 
is X". 


Example: Photuris (RFC 2522), which was published after 
IKE (RFC 2409). 


Note: In general, the IESG has no problem with rejected 
alternatives being made available to the community; such 
publications can be a valuable contribution to the technical 
literature. However, it is necessary to avoid confusion with the 
alternatives adopted by the WG. 


Inappropriate Reuse of "free" Bits: 


In 2003, a proposal for an experimental RFC was published that 
wanted to reuse the high bits of the "fragment offset" part of the 
IP header for another purpose. No IANA consideration says how 
these bits can be repurposed, but the standard defines a specific 
meaning for them. The IESG concluded that implementations of this 
experiment risked causing hard-to-debug interoperability problems 
and recommended not publishing the document in the RFC series. 

The RFC Editor accepted the recommendation. 


The RFC series is one of many available publication channels; this 
document takes no position on the question of which documents are 
appropriate for publication in the RFC Series. That is a matter for 
discussion in the Internet community. 
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6. 


9. 


oy 


T 


IAB Statement 


In its capacity as the body that approves the general policy followed 
by the RFC Editor (see RFC 2850 [I4]), the IAB has reviewed this 
proposal and supports it as an operational change that is in line 
with the respective roles of the IESG, IRTF, and RFC Editor. The IAB 
continues to monitor discussions within the IETF about potential 
adjustments to the IETF document publication processes and recognizes 
that the process described in this document, as well as other general 
IETF publication processes, may need to be adjusted to align with any 
changes that result from such discussions. 


Security Considerations 


The process change described in this memo has no direct bearing on 
the security of the Internet. 
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